It is common place to extend the functionality of an existing application such as Microsoft Excel by developing an “add-in.” An add-in is a component that the host application loads when it is needed, such as when the host application starts up or when a particular document is loaded by the host application. An add-in runs in-process with the host application rather than running in a separate process.
To launch the add-in, a user launches the host application for which the add-in has been created. The host application detects and loads registered add-ins at the appropriate time, such as at startup or when a particular document is opened. An add-in can customize the host application in multiple ways. Two common examples are that an add-in can add new menu commands, and it can modify the way the host application performs a particular operation like saving a document or printing a document.
Typically, an add-in is not written by the creators of the host application, but by third party developers that want to extend the functionality of the host application. An add-in can be created with development tools such as MICROSOFT VISUAL STUDIO .NET 2005. When a developer debugs an add-in, the developer starts the host application under a debugger such as VISUAL STUDIO .NET 2005 and attaches to the host application process because the add-in does not run in its own process space.
The above process for debugging add-ins leads to problems and a poor user experience. For example, when a developer wants to stop the add-in, the developer has to kill the host application that is hosting the add-in. For example, a developer might be debugging an add-in that is loaded within Microsoft Excel. The developer attaches the debugger to the Microsoft Excel process. If the developer is stepping through the add-in and reaches a line of code that the developer does not want to execute, the developer must stop the debugger which in turn kills the Excel process. Host applications such as MICROSOFT Excel and MICROSOFT Word were not designed to be killed at arbitrary times. These host applications may have a file open or be in the process of printing a document or be doing any number of other things that if stopped arbitrarily could cause data loss.
Another problem is that the state the host application is in is actually part of the state of the add-in being debugged. Conventional debugging tools do not show changes in the state of the host application, which makes it nearly impossible to debug host data without printing that data in another location such as a message box or console window. For example, an add-in may load into MICROSOFT Word, and when invoked the add-in searches for particular acronyms in the documents and highlights them. Conventionally, it is not possible for the developer to step through the add-in code line by line in the debugger while simultaneously viewing the changes in the document as the code is executed. The conventional debugging experience is limited, in that when stepping through add-in code if the user is stopped at a breakpoint, the host application is also stopped and is unable to refresh itself. This leads to an experience where stepping through add-in code yields no refresh of the host application and the developer cannot ascertain the effect of code written in the add-in.
Yet another problem occurs when the developer is stopped at a breakpoint in the add-in code and the developer desires to be able to interact with the host application. Conventional debuggers do not provide for this either. For example, the developer may stop at a breakpoint in add-in code where the next line of add-in code will read the value of a cell in a MICROSOFT Excel worksheet. When the breakpoint is hit, however, the developer may realize that there is not a value in the cell that is about to be read by the add-in. Thus, it would be beneficial if MICROSOFT Excel was responsive even though it is stopped at a breakpoint in the add-in code. This way the developer could enter a value in the cell and then continue the add-in code rather than have to restart the debugging session as you have to today.
Therefore, there is a need for a system of debugging add-ins that are hosted by host applications in a non-destructive manner such that the add-in can be debugged without adversely affecting the host application. The present invention provides solutions to this and other limitations in the prior art.